Contained herein is material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction of the patent disclosure by any person as it appears in the Patent and Trademark Office patent files or records, but otherwise reserves all rights to the copyright whatsoever.
1. Field of the Invention
The present invention is related to data communications. In particular, the present invention is related to hierarchical grouping of multicast traffic in an internetwork for improved, scalable, secure multicast data communications.
2. Description of the Related Art
Multicast data communications, or simply, multicast, is characterized by the transmission of data packets or frames from a source node to a plurality of destination nodes via an internetwork. If the plurality of destination nodes is sufficiently large, multicasting a data transmission significantly reduces the source node resources required to send the data transmission to each of the destination nodes, the network bandwidth consumed by the data transmission, and the latency associated with receiving the data transmission at each of the destination nodes. As pointed out in Mittra, S., Iolus: A Framework for Scalable Secure Multicasting, In Proceedings of ACM SIGCOMM ""97, it is essential that multicast (i.e., group) data communications over the Internet are secure. However, given the primarily unicast and point-to-point nature of data communications over the Internet, much of the recent work on network security is inapplicable to multicast data traffic. Indeed, in a draft document by Canetti, B., et al., A Taxonomy of Multicast Security Issues, May, 1998, a number of security issues relating to multicast traffic is discussed. What is needed is an internet security protocol designed with multicast (i.e., group) data traffic in mind.
A proposed Internet Protocol (IP) security scheme set forth in a March, 1998 Internet Engineering Task Force (IETF) Network Working Group draft of xe2x80x9cSecurity Architecture for the Internet Protocolxe2x80x9d, and recent work on multicast security, including xe2x80x9cScalable Multicast Key Distributionxe2x80x9d (Request For Comments (RFC) 1949), xe2x80x9cGroup Key Management Protocol (GKMP) Architecturexe2x80x9d (RFC 2094), xe2x80x9cGroup Key Management Protocol (GKMP) Specification (RFC 2093), and xe2x80x9cA Secure, Scalable Multicast Key Management Protocolxe2x80x9d (MKMP), indicate that multicast group data communication should use a single security association, i.e., a single key, for all multicast data traffic destined to the multicast group. However, these security schemes and security key distribution schemes are not scalable as the scope and size of the multicast group and/or network size increases. Furthermore, the prior art security schemes do not interoperate with proposed or existing IP multicast protocols such as set forth in the Multicast Extensions to OSPF specification (MOSPFxe2x80x94RFC 1584), the Distance Vector Multicast Routing Protocol (DVMRP) specification, and the Protocol Independent Multicast Sparse Mode (PIM) protocol specification. What is needed is a secure multicast scheme in which security associations may be partitioned and used only as needed in one or more portions of multicast group networks.
In some multicast data security schemes, such as Iolus, security associations for the same multicast group differ from one point to another point in the network, or from a higher level service providers to lower level service providers. For example, a securities trading service may encrypt data, e.g., stock trade and/or quote data, using a top level multicast group key, and multicast the data to several brokers. The brokers may, in turn, decrypt the multicast data using the top level multicast group key, again encrypt the data using new group keys, and then multicast the data to the ultimate destination nodes in the network.
The prior art multicast security mechanism described in Iolus divides multicast security groups into subgroups and allows security associations to differ from subgroup to subgroup. However, one disadvantage of this scheme is the latency incurred by decrypting and re-encrypting each packet of data as it is received and transmitted from subgroup to subgroup between a source node and the ultimate multicast destination nodes. Also, using local group or subgroups may result in improper execution of certain multicast data security applications that only identify and recognize a single multicast security group. What is needed, therefore, is a multicast traffic security scheme that avoids the problems described above in connection with the Iolus scheme.
The present invention partitions multicast networks into multiple, hierarchical security domains. All security domains may share the same security association, while some security domains may have their own specific security associations, and yet other security domains may not use any security. A security broker acquires a security key from an upper level security domain in the security hierarchy and distributes that key or a local domain security key, and if necessary, performs multicast data translation between the upper level security domain and the local security domain. A primary top regional security broker is elected to distribute the security key for the highest level security domain to group members in other top regional security domains in the security hierarchy. A multicast data stream may transit multiple security domains at different levels of the security hierarchy. Multicast virtual links connect security domain border routers and security brokers from security domains at the same level in the security hierarchy so that a multicast data stream may be transmitted across security domains at different levels in the security hierarchy without the need for translation when traversing a lower level security domain. Another aspect of an embodiment of the present invention relates to discovering security brokers using Bootstrap mechanism, to distributing a security key at each level in the security hierarchy using Group Request (Join or Leave) and Group Reply (accept or reject) messages between the security broker and group members of a security domain, to rekeying by delivering Group Key Refresh messages to each individual member, and to enforcing global identical secure encapsulation by multicasting Rekey Announcement messages.